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Wireless LAN Control Protocol (WiCoP) 
Abstract 


The popularity of wireless local area networks (WLANs) has led to 
widespread deployments across different establishments. It has also 
translated into an increasing scale of the WLANs. Large-scale 
deployments made of large numbers of wireless termination points 
(WIPs) and covering substantial areas are increasingly common. 


The Wireless LAN Control Protocol (WiCoP) described in this document 
allows for the control and provisioning of large-scale WLANs. It 
enables central management of these networks and realizes the 
objectives set forth for the Control And Provisioning of Wireless 
Access Points (CAPWAP). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for the historical record. 


This document defines a Historic Document for the Internet community. 
This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc5414. 
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IESG Note 


This RFC documents the WiCoP protocol as it was when submitted to the 
IETF as a basis for further work in the CAPWAP Working Group, and 
therefore it may resemble the CAPWAP protocol specification in RFC 
5415, as well as other IETF work. This RFC is being published solely 
for the historical record. The protocol described in this RFC has 
not been thoroughly reviewed and may contain errors and omissions. 


RFC 5415 documents the standards track solution for the CAPWAP 
Working Group and obsoletes any and all mechanisms defined in this 
REC. This RFC itself is not a candidate for any level of Internet 
Standard and should not be used as a basis for any sort of Internet 
deployment. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http:trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


The popularity of wireless local area networks (WLANs) has led to 
numerous but incompatible designs and solutions. The CAPWAP 
Architecture Taxonomy [RFC4118] describes major variations of these 
designs. Among them, the Local MAC (Media Access Control) and Split 
MAC architecture designs are notable categories. 


Wireless LAN Control Protocol (WiCoP) recognizes the major 
architecture designs and presents a common platform on which WLAN 
entities of different designs can be accommodated. This enables 
interoperability among wireless termination points (WTPs) and WLAN 
access controllers (ACs) of distinct architecture designs. WiCoP 
therefore allows for cost-effective WLAN expansions. It can also 
accommodate future developments in WLAN technologies. Figure 1 
illustrates the WiCoP operational structure in which distinct control 
elements are utilized for Local MAC and Split MAC WTPs. 


WiCoP also addresses the increasing trend of shared infrastructure 
WLANs. Here, WLAN management needs to distinguish and isolate 
control for the different logical groups sharing a single physical 
WLAN. WiCoP manages WLANs through a series of tunnels that separate 
traffic based on logical groups. 


The WiCoP operational structure in Figure 1 shows that each WTP uses 
a number of tunnels to distinguish and separate traffic for control 
and for each logical group. The protocol allows for managing WLANs 
in a manner consistent with the logical groups that share the 
physical infrastructure. 
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Figure 1 


In Figure 1, WiCoP establishes and operates control tunnels and 
logical group tunnels between the AC and two types of WTPs. The 
control tunnels are used to transport WiCoP messages dealing with the 
configuration, monitoring, and management of WIPs as a physical 
whole. The logical group tunnels serve to separate traffic among 
each of the logical groups constituting a physical WTP. 
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2. Terminology 
This document follows the terminologies of [RFC4118] and [RFC4564]. 
3. Protocol Overview 
The Wireless LAN Control Protocol (WiCoP) focuses on enabling 
interoperability in shared infrastructure WLANs. It is designed for 
use with different wireless technologies. This document provides 
both the general operations of WiCoP and also specific use-cases with 


respect to IEEE 802.11-based systems. 


The state machine for WiCoP is illustrated in Figure 2. 


4-------------------------------- + 

4+------------------ + 
v v | 
$------------- + $------------- + man + | 
| | | | | | | 
| Initial- | -------- >| Capabilities |-------- >| Connection | 
ization Exchange | 
$------------- + man + +------------- + | 
A A | | 
| | | | 
| | | | 
| | | | 

V 
| | po + | 
| | | | | 
| a aan | Configur- DI sil 
| | ation | | 
| | | 
+------------- + 
| | | 
| | | 
| | | 
| | | 

V 
| 4+-------------- + 
| | | | 
HZ | |-+ 
| Operation | 
| | 
4+-------------- + 

Figure 2 
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The Initialization state represents the initial states of WIPs and 
AC. A WTP or AC in this state powers on, clears internal registers, 
runs hardware self-tests, and resets network interfaces. 


The Capabilities Exchange state represents initial protocol exchange 
between a WIP and AC. A WTP in this state determines possible ACs 
from which it can receive management services. An AC in this state 
determines the capabilities of the WIP and the WTP’s compatibility 
with the management services it offers. 


The Connection state represents the creation of a security 
infrastructure between a WIP and AC. This involves mutual 
authentication and the establishment of a secure connection between 
the WiCoP entities. 


The Configuration state represents the exchange of long-term 
operational parameters and settings between a WIP and AC. A WIP in 
this state receives configuration information to allow it to operate 
consistently within the WLAN managed by the AC. An AC in this state 
provides configuration information to the WIP based on the WIP's 
capabilities and network policies. 


The Operation state represents the active exchange of WiCoP 
monitoring and management messages. WTPs send regular status updates 
to and receive corresponding management instructions from the AC. 
This state also involves firmware and configuration updates arising 
from changes in network conditions and administrative policies. 


4. WiCoP Format 


WiCoP uses separate packets for control and data message transfer 
between the AC and WIPs. A common header is used for both types of 
packets in which a single-bit flag distinguishes between them. This 
section presents the packet formats for WiCoP packets. 
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4.1. WiCoP Header 


Figure 3 illustrates the WiCoP common header for control and data 


packets. 

0 31 
| 7 15 23 | 
| ------- | ------- | coo |------- |------- |------- |-------|------- | 
| | 
4+--------------- +-+-+-4+-4+-4+-4-4-4------------------------------- + 
| Version |M|D|c|R|E|F|L| | Reserve 
4+--------------- +-+-+-4+-4+-4+-4-4-4------------------------------- + 
| Fragment ID | Fragment No. | Length 
4+--------------- 4+--------------- $ o + 


Version Field 
This field indicates the protocol version. 
'M’ Field 


The MAC-type field, ’M’, distinguishes between Local MAC WTPs and 
Split MAC WTPs. It is used to efficiently realize interoperability 
between WIPs of the two different designs. A '0” value indicates 
WiCoP exchanges with a Split MAC WIP while a ’1’ value indicates 
WiCoP exchanges with a Local MAC WTP. 


The presence of this classification bit in the WiCoP common header 
serves to expedite processing of WiCoP and WLAN traffic at the AC. 
With a single parsing of the WiCoP common header once, the AC will be 
able to determine the appropriate processing required for the 
particular WiCoP packet. 


"D' Field 


The differentiator field, 'D', is used to distinguish between WTP 
variants within a type of WIP design. The CAPWAP Architecture 
Taxonomy [RFC4118] illustrates that the Split MAC design allows 
encryption/decryption to be performed at either the WTP or the AC. 
The Architecture Taxonomy also indicates that the Local MAC design 
allows authentication to take place at either the WTP or the AC. 
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WiCoP acknowledges these major variants and accommodates them using 
the 'D” field in conjunction with the 'M” field. For a Split MAC 
WIP, the 'D” field is used to indicate location of 
encryption/decryption while for a Local MAC WIP, the 'D” field is 
used to indicate location of authentication. The following table 
highlights their usage. 


"M' CDs Description 
0 0 Split MAC WIP - Encryption/decryption 
is performed at WIP 
0 1 Split MAC WIP - Encryption/decryption 
is performed at AC 
Í 0 Local MAC WIP - Authentication is 
performed by WTP 
I 1 Local MAC WIP - Authentication is 


performed by AC 


Similar to the ’M’ field, the presence of this classification in the 
WiCoP common header helps expedite processing at the AC with a single 
parsing. By incorporating the classification bits in the WiCoP 
common header, where it is available for all packets of a session, 
the AC processing can be expedited. Alternatively, the AC would have 
to check each arriving packet against an internal register and 
consequently delay processing. 


'C’ Field 


This field distinguishes between a WiCoP control and WiCoP data 
packet. Each type of information is tunneled separately across the 
WiCoP tunnel interfaces between WIPs and the AC. A '0” value for the 
'C’ field indicates a data packet, while a ’1’ value indicates a 
control packet. 


The ’C’ field is also used to assign WiCoP packets to distinct data 
and control tunnels between the AC and WIP. WiCoP also maintains 
logical groups in WLANs with the ’C’ field. 


"R” Field 


The retransmission field, 'R', is used to differentiate between the 
first and subsequent transmissions of WiCoP packets. The ’R’ field 
is used for critical WiCoP packets such as those relating to security 
key exchanges. A ’0’ value for the ’R’ field indicates the first 
transmission of a WiCoP packet, while a ‘1’ value indicates a 
retransmission. 
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“E” Field 


The encryption field, 'E', is used to indicate if the WiCoP packet is 
encrypted between the AC and WIPs. The 'E” field is used for those 
WiCoP packets that are exchanged during initialization. A 0” value 
indicates the WiCoP packet is unencrypted, while a '1' value 
indicates the packet is encrypted. 


"EF! Field 


The fragmentation field indicates if the packet is a fragment of a 
larger packet. A ’0’ value indicates a non-fragmented packet while a 


/1 value indicates a fragmented packet. The ‘’F’, 'L', 'Fragment 
ID’, and 'Fragment No.’ fields are used together. 
'L’ Field 


This field is used to indicate the last fragment of a larger packet. 
It is only valid when the ’F’ field has a '1' value. A ‘’0’ value for 
the ’L’ field indicates the last fragment of a larger packet while a 
/1 value indicates an intermediate fragment of a larger packet. The 
'F’, 'I!, ‘Fragment ID’, and 'Fragment No.” fields are used together. 


Fragment ID Field 


The Fragment ID identifies the larger packet that has been 
fragmented. It is used to distinguish between fragments of different 
large packets. This field is valid only when the 'F” field has a '1' 
value. The 'F', 'I!, 'Fragment ID’, and 'Fragment No.’ fields are 
used together. 


Fragment No. Field 


The fragment number field identifies the sequence of fragments of a 
larger packet. The value of the Fragment No. field is incremented 
for each fragment of a larger packet so as to show the order of 
fragments. This field is valid only when the ’F’ field has a '1' 
value. The 'F', 'I!, 'Fragment ID’, and 'Fragment No.’ fields are 
used together. 


Length Field 


This field specifies the length of the WiCoP payload following the 
header. 
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4.2. WiCoP Control Packet 


The WiCoP control header follows the WiCoP common header. It is 
highlighted in Figure 5. 


0 31 
| 7 15 23 | 
|------- |------- | eo] |-------|------- |-------|------- | 
| | 
POSAS ERASE a a qe === ah + 
| Msg Type Reserve | Seq Num 

a SSeS li aS SSS = SSS SS Se + 
| Msg Element Length | 

SSS Sa ee eS a + 

Figure 5 


The control packet adds four additional fields to the common header. 
These are described below: 


Msg Type Field 

The message type field specifies the type of control message 
transported in the packet. The list of control messages is presented 
in Section 5.2.1. 

Seq Num Field 

The sequence number field is used to map WiCoP request and response 
sequences. The initiator of a WiCoP request message increments the 
Seq Num field for each new request message. The responder then uses 
these values of the Seq Num fields in its corresponding response 
messages. 


Msg Element Length Field 


This field specifies the length in bytes of the subsequent WiCoP 
control message element. 
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4.2.1. WiCoP Control Messages 


The list of WiCoP control messages is shown below: 


Message Msg Type 
Capabilities 1 
Capabilities Response 2 
Connection 3 
Connection Response 4 
Configuration Request 5 
Configuration Response 6 
Configuration Data 7 
Configuration Data Response 8 
Configuration Trigger 9 
Configuration Trigger Response 10 
Feedback 11 
Feedback Response 12 
Reset 13 
Reset Response 14 
Firmware Download 15 
Firmware Download Response 16 
Terminal Addition 17 
Terminal Addition Response 18 
Terminal Deletion 19 
Terminal Deletion Response 20 
Key Configuration 21 
Key Configuration Response 22 
Notification 23 
Notification Response 24 


4.2.2. WiCoP Control Message Elements 


WiCoP control messages each include a control message header followed 
by one or more message elements. The message elements are shown in 
the following table: 
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WTP-Info 


Cap-from-WTP 
Conf-If-Data 
Conf-WTP-Data 
Cap-to-WTP 


Timer-Init-Value 


Terminal-Data 


BSSID 


Encryption-Data 
FAP-Frame 


Statistics 


Interface-Error 


FROM-Error 


+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
QoS-Value | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


QoS-Capability 
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Information regarding WIPs, such as 
manufacturer ID, MAC address, etc. 


Quality-of-Service (QoS) abilities 
(WME-Wireless Multimedia Extension) 
and security abilities 

(IEEE 802.111) are included 


Physical Layer (PHY) information for 
each wireless interface 


Information regarding logical 
groups on a per-logical group basis 


(e.g., per-virtual AP) 


Setup data sent to WIPs by an AC on 
a per-logical group basis 


QoS setup (access categories) 


Initial values of timers such as 
aging, echo interval, etc. 


Information relevant to wireless 
terminals - Basic Service Set 
Identifier (BSSID), association ID, 
SEC. 


BSSID, and terminal MAC address 


Details of the security framework - 
cipher suit, operation mode, etc. 


Extensible Authentication Protocol 
(EAP) frame 


Various statistics information - 
transmission attempts, Frame Check 
Sequence (FCS) errors, etc. 

Type of wireless interface failure 


Flash ROM Error information 


Network congestion information 
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Key (GTK) - new or existing 


| | | | 

| TFTP-Data | 16 | Firmware-related details 

| Result | 17 | Result of protocol operations - 

| | | success or failure | 

| | | | 

| OID | 18 | Simple Network Management Protocol | 

| | | (SNMP) Object Identifiers (OIDs) | 

| GTK-Flag | 19 | Determines type of Group Temporal 

| | | | 
+ + 


Each message element comprises a number of information items that are 
detailed below. The length of each information item is specified in 
bytes. 


WIP-Info: 


Information included in the WIP-Info message element is provided on a 
per-WTP basis, i.e., each WIP exchanges one WIP-Info message element. 


4+-------------- 4+---------- 4+---------------- 4+------------------------ + 

| Item | Length | Syntax | Description 

4+-------------- 4+---------- 4+---------------- 4+------------------------ + 

| Manufacturer | 8 | DisplayString | Manufacturer ID 

| ID | | | | 

| MAC Address | 6 | PhyAddress | WTP MAC Address 

| | | | | 

| Firmware | 8 | DisplayString | Firmware version of 

| Version | | | WTP 

| | | | | 
Start Time 4 TimeTicks Starting time of WTP 

(UNIX Time) 
4+-------------- 4+---------- 4+---------------- +------------------------ + 


Cap-from-WTP: 
Information included in the Cap-from-WTP message element is provided 


on a per-WTP basis, i.e., each WTP exchanges one Cap-from-WTP message 
element. 
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802.11e Cap 
Length 


802.1le 
Capabilities 


802.111 Cap 
Length 


802.111 
Capabilities 


AuthType 


Conf-If-Data 


The Conf-If-Data message element relates to the wireless interface. 


5 _ _—__ A _A _A  _ÁA-_ Ah 


Variable 


Variable 


WiCoP 


OCTETString 


Integer 


OCTETString 


OCTETString 


February 2010 


Description 


Length of 802.1le 
capabilities 


802.1le capabilities 
of WIP. If WIP does 
not have such 
capabilities, this 
field is filled with 
pr 


Length of 802.11i 
capabilities 


802.11i capabilities 
of WIP. If WIP does 
not have such 
capabilities,this 
field is filled with 
LAYO Bd 


Type of authentication 
mechanism used between 


WTPs and the AC 


A WIP with many interfaces will include corresponding numbers of 


Conf-If-Data message elements within its control messages to the AC. 
Conf-If-Data message elements are indexed by the If ID information 


item. 
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+-------------- to +---------------- 
| Item | Length | Syntax 
Ho +---------- +--------------—- 
| If ID |i | Integer 
| | | 
| | | 
| | | 
| Current |1 | Integer 
| Power | | 
| | | 
| Radio ee | Integer 
| Channel | | 
| | | 
| 2Dot 4Mode pa! | Integer 
| | | 
+-------------- to +---------------- 


Conf-WTP-Data 


Configuration information is provided on the basis of logical groups 


February 2010 


Description 


Denotes identification 
of a wireless 
interface 


Current Power Level 
(117 = Max; '2! = 1/2, 
13% SALAS TA? = 1/8 


Radio channel of 
operation 


Interface mode in 
2.4GHz. ('1' 
802.11b, '2' 
802.119, '3’ = Both) 


such as virtual APs. There are multiple Conf-WIP-Data message 


elements to address the many logical groups within a WLAN managed by 


WiCoP. Conf-WTP-Data message elements are indexed by the BSSID 


information item. 


4+-------------- 4+---------- 4+---------------- 
| Item | Length | Syntax 
4+-------------- +---------- +---------------- 
| BSSID | 6 | OCTETString 
| | | 
| ESSID | 32 | OCTETString 
| | | 
| BSSID - | 32 | OCTETString 
| TunnelID | | 
| | | 
| Beacon | a | Integer 
| Period | | 
| | | 
| DTIM Period | 1 | Integer 
| | | 
| | | 
Iino, et al. Historic 


Extended Service Set 
Identifier (ESSID) 


Mapping for logical 
groups across BSSID 
and WiCoP tunnels 


Time interval between 
Beacon transmissions 


Delivery Traffic 
Indication Message 
(DTIM) period of 
Beacon transmissions 


A AA AA AA A A ee + 
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AnyRejectFla 
g 


SSID Stealth 
Flag 


Operation 
Rate Set 


Encryption 
Type 


Encryption 
Key 


Cap-to-WTP: 


+ _ zz  —==—————————24—24=24=4=424 +44 
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Integer 


Integer 


Integer 


Integer 


OCTETString 
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Flag indicating WTP 
rejection of any Probe 
Request within any 
SSID - ('1' = 
Rejected; '2” = Not 
Rejected) 


Flag indicating 
inclusion of ESSID 
within Beacon Frames 
(11 = ESSID included; 
12 = ESSID not 
included) 


Data rates supported 
by WTP for terminal 
being added using a 
12-bit format for 1.1, 
2227 AED 4.67 DB 
bully 712, 8318 
95247. 10.367, 11:48, 
and 12.54 Mbps 


Encryption Type - 
&#65288;'1"' = OFF; '2! 
= WEP40; '’3’ = WEP104; 
ra” = WEP128) 


Static Encryption Key 


Capabilities information is provided on the basis of logical groups 
there are multiple Cap-to-WTP message 


such as virtual APs. So, 


elements to address the many logical groups within a WLAN managed by 
Conf-to-WTP message elements are indexed by the BSSID 
If logical groups are created by other means, 


WiCoP. 
information item. 


their corresponding identifier is used as the index. 
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+-------------- +---------- 4+---------------- Ho + 
| Item | Length | Syntax | Description 
+—-------------- +---------- 4+—---------------- +---------------------- + 
| BSSID | 6 | OCTETString | BSSID | 
| | | | | 
| 802.1le Cap | 2 | Integer | Length of 802.1le 
| Length | | | capabilities 
| | | | | 

802.11e Variable OCTETString 802.1le capabilities 
Capabilities of WIP. If WIP does 
| | | | not have such 
| | | | capabilities, this | 
| | | | field is filled with | 
| | | ees | 
| | | | | 
802.111 Cap 2 Integer Length of 802.11i 
| Length | | | capabilities 
| | | | | 
| 802.111 | Variable | OCTETString | 802.11i capabilities | 
| Capabilities | | | of WIP. If WIP does | 
| | | | not have such 
capabilities, this 
field is filled with 
| | | | or | 
+-------------- +---------- 4+---------------- Ho + 
QoS-Value: 
QoS parameters are assigned for each logical group to address their 
respective individual conditions and requirements. QoS-Value message 
elements are provided on a per-logical group basis. They are indexed 


by the BSSID information item. 
other means, 
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+-------------- +--------—- +--------------—- Ho ==> + 
| Item | Length | Syntax | Description 
+-------------- +--------—- +---------------- Ho ===> + 
| BSSID | 6 | OCTETString | BSSID | 
| | | | | 
| WTP AC BE | 2 | Integer | AC Parameters Record 
| | | | AC_BE in WTP | 
| | | | | 

WTP AC_BK 2 Integer AC Parameters Record 

AC_BK in WTP 

| | | | | 
| WTP AC_VI Ke: | Integer | AC Parameters Record 
| | | | AC_VI in WTP | 
| | | | | 
| WTP AC_VO |2 | Integer | AC Parameters Record 
| | | | AC_VO in WIP | 
| TE AC_BE | 2 | Integer | AC Parameters Record 
| | | | AC_BE in terminals | 
| | | | | 
| TE AC_BK | 2 | Integer | AC Parameters Record 
| | | | AC BK in terminals | 
| TE AC_VI Ng | Integer | AC Parameters Record 
| | | | AC_VI in terminals | 
| | | | | 
| TE AC Vo | 2 | Integer | AC Parameters Record 
| | | | AC_VO in terminals | 
Pr a +---------- +---------------- Ho ===> + 
Timer-Init-Value: 
WiCoP timers are used for the WTP as a whole. So, the Timer-Init- 


Value message element is provided on a per-WIP basis. 


Iino, et al. 


Historic 


[Page 19] 


RFC 5414 WiCoP February 2010 


PAGA PAG PET AG PAL a SS + 

| Item | Length | Syntax | Description 

Ha por a ieee a ee Sa a en + 

| BSSID | 6 | OCTETString | BSSID | 

| | | | | 

| Response | 4 | Integer | Initial value of 

| Timer | | | Response Timer 

| | | | | 
Active 4 Integer Initial value of 
Presence Active Presence Timer 

| Timer | | | | 

| | | | | 

| Feedback | 4 | Integer | Initial value of 

| Interval | | | Feedback Interval 

| Timer | | | Timer | 

FE PG eA PAG 2222 + 


Terminal-Data: 


The Terminal-Data message element is applicable for both Local MAC 
and Split MAC WTP designs. In the case of Local MAC, Terminal-Data 
is sent from WIPs to the AC. In the case of Split MAC, Terminal-Data 
is sent from the AC to WIPs. So, the direction of usage depends on 
the type of WIP at which wireless terminal operations are performed. 
Some information items may be optional for use with specific WTP 
designs. 
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+-------------- +---------- +---------------- +------------------------ + 

| Item | Length | Syntax | Description 

+-------------- Ho +---------------- +------------------------ + 

| BSSID | 6 | PhyAddress | BSSID in which 

| | | | terminal is being | 

| | | | added | 

| 

| MAC Address | 6 | PhyAddress | MAC address of 

| | | | terminal being added | 

| Association | 2 | Integer | Association ID of 

| ID | | | terminal being added | 

| | 

| Operation | 2 | Integer | Data rates supported 

| Rate Set | | | by WTP for terminal 
being added using a 

| | | | 12-bit format for 1.1, | 

| | | VEZ B56 MG. 5495 

| | | | 6.11, 7.12, 8.18, | 

| | | | 9.24, 10.36, 11.48, | 

| | | | and 12.54 Mbps | 

| Listen | 2 | Integer | Listen period 

| Period | | | | 

+-------------- +---------- +---------------- +------------------------ + 

BSSID: 


The BSSID message element is used to identify logical groups within a 
WLAN. WiCoP may be extended for other types of logical groups by 
simply including additional message elements. 


+-------------- +---------- 4+—---------------- +---------------------- + 
| Item | Length | Syntax | Description 
+-------------- +---------- 4+---------------- Ho + 
| BSSID | 6 | PhyAddress | BSSID in which 
| | | | terminal is being | 
| | | | added | 
| | | | | 

MAC Address 6 PhyAddress MAC address of 

terminal being added 

+-------------- +---------- 4+---------------- Ho o + 


Iino, et al. Historic [Page 21] 


RFC 5414 


Encryption-Data 


WiCoP 


February 2010 


The Encryption-Data message element contains information relevant for 


configuring security keys at WTPs. 


It is used in architectures in 


which the authentication and encryption points are located in 
distinct WLAN entities. 


MAC Address 


Operation 


Key Index 


Key Flag 


Cipher Suit 


EAP-Frame: 


+ 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


32 


PhyAddress 


Integer 


Integer 


Integer 


Integer 


OCTETString 


A a a E A A E RA a a St + 


Description 


MAC address of 
terminal 


Operational Mode ('1' 
= Set Key; '2! = 
Delete Key) 


Key Index - valid when 
Operational Mode = Set 
Key 


Key Flag ('1' = 
Unicast Key or PTK; 
n2" = Broadcast Key or 
GTK) - valid only when 
Operational Mode = Set 
Key 


Encryption Type ('1' = 
WEP40; "2 = WEP104; 
"3! = WEP128, '4! = 
TKIP; '5 = AES) - 
valid only when 
Operational Mode = Set 
Key 


Key body - valid only 
when Operational Mode 
= Set Key 


The EAP-Frame message element is used to carry EAP frames used in the 
configuration and management of the WLAN. 
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+-------------- +---------- 4+—---------------- Ho o + 
| Item | Length | Syntax | Description 
+-------------- +---------- 4+---------------- Ho o + 
| MAC Address | 6 | PhyAddress | MAC address of 
| | | | terminal | 
| | | | | 
| EAP | Variable | OCTETString | EAP Frames | 
+-------------- +---------- 4+—---------------- +---------------------- + 
Statistics: 
Statistics information covers all aspects of WTPs. As such, this 
message element is provided on a per-WTP basis. WiCoP messages 
containing the Statistics message element simultaneously serve as 
keepalive signals between WTPs and the AC. 
4+-------------- +---------- 4+---------------- Ho oo + 
| Item | Length | Syntax | Description 
+-------------- +---------- 4+---------------- +---------------------- + 
| OutOctet | 4 | Counter 32 | Octet number of frame | 
| | | | WTP transmits | 
| Transmit | 4 | Counter 32 | Total number of frames | 
| Count | | | transmitted by WTP | 
| | | | | 
| Successful | 4 | Counter 32 | Total number of ACKs 
| Transmit | | | received | 
Dr. | | | | 
| ACK Failure | 4 | Counter 32 | Total number of failed | 
| Count | | | ACKs | 
| | | | | 
| InOctets | 4 | Counter 32 | Octet number of frame | 
| | | | WIP receives | 
| Receive | 4 | Counter 32 | Total number of frames | 
| Count | | | received by WTP | 
| | | | | 
| Receive | 4 | Counter 32 | Total number of 

Discard received frames that 

are discarded 

| | | | | 
| Retransmissi | 4 | Counter 32 | Number of WTP 
| on Count | | | retransmission 
| | | | attempts" | 
| | | | | 
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Duplicate 
Receive 
Count 


FCS Error 
Receive 
Count 


Unknown 
Frame 
Receive 
Count 


Beacon 
Transmit 
Count 


Probe 
Transmit 
Count 


Probe 
Receive 
Count 


Decrypt CRC 
Error Count 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 


Interface-Error: 


WiCoP 


Counter 32 


Counter32 


Counter 32 


Counter 32 


Counter 32 


Counter 32 


Counter 32 


++ GC 


nn i 


February 2010 


Number of duplicate 
frames received by WTP 


Number of frames 
received with FCS 
errors 


Number of unknown 
protocol frames 
received 


Beacon frames 


Number of transmitted 
Probe Response frames 


Number of received 
Probe Response frames 


Number of received 


| 

| 

| 

| 

| 

| 
Number of transmitted | 
| 

| 

| 

| 

| 

| 

| 
frames that cannot | 
| 


This message element is used to exchange information on error 
conditions related to the wireless interface. 


Tino, 


Interface 
Index 


Error Type 


et al. 


Historic 


+ 
| 
+ 
| 


+ —_—. 


decrypt 
A O A MEI SA + 
SARA EA A ER + 
Description | 
a OS ka a Aa a a ÓN + 
Interface ID 
Type of error ('1' = | 
Unrecoverable; '2' = | 
Recoverable) | 
gs in a bi a an Ny Sind ck ga Sed So an nd a + 
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FROM-Error: 


WiCoP 


February 2010 


The FROM-Error message element is used to exchange information on 


error conditions related to flash ROMs in 


ma + 
| Item | 
ma + 
FROM Index 
| Error Type | 
| | 
| | 
$-------------- + 


QoS Capability: 


+—+ 


WIPs or the AC. 


The QoS-Capability message element is used to exchange information 


concerning the Enhanced Distributed Channel Access 


Controlled Chann 


4+-------------- + 
| Item | 
4+-------------- + 
| EDCA | 
| | 
| | 
HCCA 

| | 
| | 
4+-------------- + 
TFTP-Data: 


el Access 


( 


+ 
| 
+ 
| 
| 
| 


+ 4 


This message element is for 


Iino, et al. 


---------------- $ 
Syntax | Description 
---------------- +------------------------+ 
Integer FROM ID 
Integer | Type of error ('1' = | 
| Unrecoverable; "2 = | 
| Recoverable) | 
---------------- $ 
(EDCA) and HCF 
HCCA) capabilities of WTPs. 
---------------- +------------------------+ 
Syntax | Description 
---------------- +------------------------+ 
Integer | EDCA Capability ('1' = | 
| Capable; '2’ = Not | 
| capable) | 
Integer HCCA Capability ('1' = 
| Capable; '2' = Not | 
| capable) | 
---------------- +------------------------+ 
firmware data from an AC to WTPs. 
---------------- +------------------------+ 
Syntax | Description 
---------------- +------------------------+ 
OCTETString | Details of Trivial File| 
| Transfer Protocol | 
| (TFTP) | 
---------------- +------------------------+ 
Historic [Page 25] 
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Result: 


The Result message element is used in all WiCoP response messages to 
indicate the status of WiCoP request messages. 


Ho +---------- Ho +------------------------ + 
| Item | Length | Syntax | Description 
Ho +---------- Ho Pr ooo + 
| Result Code | 1 | Integer PELS = OK; NON = NG 
Ho +---------- Ho Ho ooo + 
OID: 


The OID message element is used for general configuration information 
specified by OIDs. 


PER EG Hm a AO SS EGGS + 

| Item | Length | Syntax | Description 

$ do $ AZ ETE E + 

| Length | 1 | Integer | Length of OID String 

| | | | and OID Value | 
OID String Variable OCTETString Object Identifier that 

| | | | is assigned according | 

| | | | to Basic Encoding | 

| | | | Rules (BER) | 

| | | | | 

| Value | Variable | OCTETString | Value 

AREE Ss ta tans MAA a Se Se ee + 

GTK-Flag: 


The GIK-Flag message element is used to inform the WIP on the type of 
GTK used and correspondingly how the KeyMIC is to be computed. 


+-------------- to +---------------- +------------------------ + 
| Item | Length | Syntax | Description 
+-------------- +---------- +---------------- +------------------------ + 
| GTK Flag | 1 | Integer | Determines the type of | 
GTK ('1! = New; '2! = 
Existing) 
Ho +---------- Ho +------------------------ + 
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4.2.3. WiCoP Control Message Description 


Message: Capabilities 
Direction: WIP -> AC 
Type: Request 


Description: WIPs send a Capabilities message upon transitioning from 
the Initialization state to the Capabilities Exchange state. The 
message serves to discover and identify the controlling AC of the 
WLAN and to provide it with identification and capabilities 
information. In the IEEE 802.11 use-case, the Capabilities message 
also specifies the WTP’s IEEE 802.1le and IEEE 802.11i features. 


TLV: The Capabilities message includes message elements of types 1 
and 2. 


| WIP-Info | 


| Cap-from-WIP | 


Message: Capabilities Response 
Direction: AC -> WIP 
Type: Response 


Description: This message is sent by an AC after examining the 
compatibility of the WIP and its capabilities. The compatibility is 
with respect to the MAC architecture that can be supported by the AC. 
If the WIP is determined to be compatible, the Capabilities Response 
message also contains information on the capabilities of the AC. 


TLV: The Capabilities Response message includes message elements of 


types 5 and 17. The Cap-to-WIP message elements are distinguished 
based on BSSIDs to represent different logical groups. 
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| Cap-to-WTP 1 | 
| | 
| Cap-to-WIP ... | 
| | 
| | 


Cap-to-WTP n 


Message: Connection 
Direction: WIP -> AC 
Type: Request 


Description: The Connection message initiates the mutual security 
association between an AC and WTPs. This message carries the first 
message of the chosen security protocol. The specific security 
mechanism for the authentication is out of scope of the WiCoP 
specifications. 


TLV: The Connection message includes message elements of type 2. 


$--------------- + 
| Connection | 
$--------------- + 
| Cap-from-WIP | 
$--------------- + 


Message: Connection Response 
Direction: AC -> WTP 
Type: Response 


Description: After completion of the security protocol exchange, this 


message indicates the result of the WIP-AC security association. If 
successful, it also represents the admission of the WTP into the 
WLAN. 


TLV: Type 17 message element is included. 


ii + 
| Connection Response | 
AGA AA KANA + 
| Result | 
AGA UA + 
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Message: Configuration Request 
Direction: WIP -> AC 
Type: Request 


Description: This message starts the Configuration state for the WIP. 
It is a request for configuration information from the WTPs to the 
AC. 


Message: Configuration Response 
Direction: AC -> WIP 
Type: Response 


Description: This is an acknowledgement for the Configuration Request 
message. 


TLV: Type 17 message element is included. 


la E + 
| Configuration Response | 
PEE + 
| Result | 
SAS S + 


Message: Configuration Data 
Direction: AC -> WTP 
Type: Request 


Description: Configuration information including operational 
parameters, QoS settings, and timer values is sent using the 
Configuration Data message. This message is also used for 
configuration updates in the Operation state of WiCoP. 


TLV: This message includes message elements of types 3, 4, 5, 6, and 
7. The Conf-WIP-Data and QoS-Value message elements are identified 
by BSSIDs to denote logical groups, while the Conf-If-Data message 
elements are identified by If-IDs to denote multiple wireless radios. 
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+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 

Message: Configuration 

Direction: 

Type: Response 

Description: 

message. 


TLV: Type 17 message element is included. 


Message: 


Tino, 


et al. 


Request 


WiCoP 


Conf-If-Data 1 
Conf-If-Data 
Conf-If-Data n 
Conf-WIP-Data 1 
Conf-WTP-Data 
Conf-WIP-Data n 
Cap-to-WTP 1 
Cap-to-WTP 
Cap-to-WTP n 
QoS-Value 1 
QoS-Value 
QoS-Value n 


Timer-Init-Value 


Data Response 


Configuration Trigger 
Direction: 


Type: 


Historic 
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This is an acknowledgement for the Configuration Data 
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Description: This message is used to trigger the activation of the 
configuration information sent in earlier Configuration messages. 


Message: Configuration Trigger Response 
Direction: WIP -> AC 
Type: Response 


Description: This is an acknowledgement of the Configuration Trigger. 
This response message is sent before activation of the configuration 
information. 


TLV: Message elements of type 17 are included. 


+-------------------------------- + 
| Configuration Trigger Response | 
+-------------------------------- + 
| Result | 
+-------------------------------- + 


Message: Reset 
Direction: AC -> WTP 
Type: Request 


Description: This message from the AC instructs the WTP to clear 
registers and revert to initial conditions. 


Message: Reset Response 
Direction: WTP -> AC 
Type: Response 


Description: This is an acknowledgement for the Reset message to the 
AC. 


TLV: Message elements of type 17 are included. 


A 7-77-77 + 
| Reset Response | 
a a Soe + 
| Result | 
A + 


Message: Feedback 
Direction: WTP <-> AC 
Type: Request 
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Description: 
WIP: The Feedback message is used to send regular statistics 
information to the AC. It also serves as a keepalive 


indicator used to update the Active Presence Timer 
maintained by the AC. 

AC: The Feedback message is used to determine the active state 
of WIPs. 


TLV: This message includes message elements of type 12. 


$ + 
| Feedback | 
$ + 
| Statistics | 
$ + 


Message: Feedback Response 
Direction: WTP <-> AC 
Type: Response 


Description: This is an acknowledgement for Feedback messages. 


TLV: Message elements of type 17 are included. 


$ + 
| Feedback Response | 
AE + 
| Result | 
tenes SSeS SRS SSeS + 


Message: Firmware Download 
Direction: AC -> WIP 
Type: Request 


Description: This message is used to instruct WIPs to update their 
firmware. The message element contains information regarding the new 


firmware. 


TLV: Message elements of type 16 are included. 


+------------------—- + 
| Firmware Download | 
+------------------—- + 
| TFTP-Data | 
+------------------- + 
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Message: Firmware Download Response 
Direction: WIP -> AC 
Type: Request Response 


Description: This is an acknowledgement for the Firmware Download 
message. 


TLV: Message elements of type 17 are included. 


+---------------------------- + 
| Firmware Download Response | 
+---------------------------- + 
| Result | 
HO + 


Message: Notification 

Direction: WTP <-> AC 

Type: Request 

Description: This message is used to indicate non-periodic events. 
It may be sent by either WTPs or the AC. Notification messages 
indicate failures, non-periodic changes, etc. 


TLV: Message elements of types 13 and 14 are included. 


| Interface-Error | 
| FROM-Error | 
Message: Notification Response 
Direction: WTP <-> AC 


Type: Response 


Description: This is an acknowledgement for the Notification message. 
It may be followed by Configuration messages to rectify errors. 


TLV: Message elements of type 17 are included. 


$----------------------- + 
| Notification Response | 
4----------------------- + 
| Result | 
$----------------------- + 
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Message: Terminal Addition 
Direction: WTP <-> AC 
Type: Request 


Description: This message may be sent from WIPs or the AC, depending 
on the WIP type in consideration. In both cases, it is sent in 
response to an IEEE 802.11 association frame. 


For Split MAC WIPs, Terminal Addition is sent from the AC to the WIPs 
and includes information on the wireless terminal relevant to the 
WIP. 


For Local MAC WIPs, Terminal Addition is sent from a WTP to the AC 
and contains information on the wireless terminal relevant to the AC. 


TLV: Message elements of type 8 are included. 


+------------------- + 
| Terminal Addition | 
+------------------—- + 
| Terminal-Data | 
+------------------—- + 


Message: Terminal Addition Response 
Direction: WTP <-> AC 
Type: Response 


Description: This is an acknowledgement sent from either WTPs or the 
AC, depending on the WTP type in consideration. 


TLV: Message elements of type 17 are included. 


+---------------------------- + 
| Terminal Addition Response | 
+---------------------------- + 
| Result | 
+---------------------------- + 


Message: Terminal Deletion 
Direction: WTP <-> AC 
Type: Request 


Description: This message is sent in response to a disconnection of a 


wireless terminal. It can be sent from WTPs or the AC. In both 
cases, Terminal Deletion instructs the recipient to remove any state 
information relating to the specific wireless terminal. The message 
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is sent in response to an IEEE 802.11 disassociation frame, IEEE 
802.11 deauthentication frame, or due to the expiration of the Active 
Presence Timer. 


For Split MAC WIPs, Terminal Deletion is sent from the AC to the 
WIPs. 


For Local MAC WIPs, Terminal Deletion is sent from the WIPs to the 
AC. 


TLV: Message elements of type 9 are included. 


4------------------- + 
| Terminal Deletion | 
4------------------- + 
| BSSID | 
4------------------- + 


Message: Terminal Deletion Response 
Direction: WIP <-> AC 
Type: Response 


Description: This is an acknowledgement sent from either WIPs or the 
AC, depending on the WiCoP interface. 


TLV: Message elements of type 17 are included. 


HO + 
| Terminal Addition Response | 
+---------------------------- + 
| Result | 
HO + 


Message: Key Configuration 
Direction: AC -> WIP 
Type: Request 


Description: This message is used when authentication and encryption 
points are located in distinct WLAN entities. WiCoP uses it in cases 
where 'M” = 0 and 'D” = 0 or where ’M’ = 1 and 'D” = 1. It is used 
to configure security key information from the AC to the WIPs. 


TLV: The following message elements are included for Key 
Configuration. 
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| 

| 

| Encryption-Data 
| 

| EAP-Frame 


Message: Key Configuration Response 
Direction: WIP -5 AC 
Type: Response 


Description: This is an acknowledgement for the Key Configuration 
message. 


TLV: Message elements of type 17 are included. 


$a SS SSS a eee SS + 
| Key Configuration Response | 
+---------------------------- + 
| Result | 
PS SSS SSeS See SSeS SSeS Sea + 


4.3. WiCoP Data Packet 


WiCoP data packets include the WiCoP common header followed by a 
payload. Data packets are used to distinguish traffic from control 
when both control and data paths are identical. Such a scenario 
would involve data traffic of the WIPs traversing the AC. However, 
given the diversity of large-scale WLAN deployments, there are 
scenarios in which data and control paths are distinct. WiCoP can be 
used in both cases. 


The WiCoP data packet format is illustrated below in Figure 7, 
together with the WiCoP common header. 
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0 31 
| 7 15 23 | 
AAA PAN PO PU | ------- —------|------- eee eee 
4+--------------- +-+-+-4+-4+-4+-4-4-4------------------------------- + 
| Version |M|D|c|R|E|F|L| | Reserve 
4+--------------- +-+-4+-4+-4+-4+-4-4-4------------------------------- + 
| Fragment ID | Fragment No. | Length 
+--------------- +--------------- Pa + 
| Payload | 
Pa + 
Figure 7 


4.4. WiCoP Timers 


WiCoP uses a number of timers to determine WLAN status and maintain 


system performance. Timers are maintained by all WiCoP entities. 
4.4.1. Active Presence Timer 
The Active Presence Timer is used by each WiCoP entity -- AC and WIPs 


-- to verify the presence of each other. The absence of a reply to 
the Feedback message within the expiration of the Active Presence 
Timer indicates the corresponding entity is inactive. Contingency 
operations such as reset are used in this case. The value of the 


Active Presence Timer ranges from 10 to 300 seconds with a default 
value of 30 seconds. 


4.4.2. Feedback Interval 


Feedback messages are periodic with the frequency defined by the 


Feedback Interval. The interval is set during WTP configuration. It 
has a value ranging from 1 to 100 seconds and a default value of 10 
seconds. 


The Feedback Interval timer sets the periodicity of WLAN system 
audits. So with this timer, the WLAN controller receives regular 
information on the state of the WLAN and all its WIPs. 


4.4.3. Response Timer 


This is a general-purpose timer used to limit the elapsed time 
between transmission of a request message and receipt of a 
corresponding response message. The value of this timer ranges from 
1 to 3 seconds with a default value of 1 second. 
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4.4.4. Wireless Connectivity Timer 


This timer triggers any changes in wireless connectivity. WiCoP uses 
this timer to send Notification and other messages relating to 
wireless conditions. It is also used to trigger the disconnection of 
mobile terminals without disassociation. The value of the Wireless 
Connectivity Timer ranges from 1 minute to 86,400 minutes with a 
default value of 10 minutes. 


5. WiCoP Processes 
The processes of the Wireless LAN Control Protocol are described in 
this section with respect to the operational state in which they 
occur. 
5.1. Initialization 
The Initialization state represents the initial conditions of WiCoP 
entities. WTPs and ACs in this state are powered on, run hardware 
self-check tests, and reset network interfaces. 
State transition: Initialization -> Capabilities Exchange 
WTP: Automatically upon detecting an active network interface 
AC: Upon receiving a Capabilities message from a WIP 


5.2. Capabilities Exchange 


The Capabilities Exchange state allows WIPs to first find an AC and 
then to exchange capabilities information with it. 


WiCoP is designed to control WLANs with both Local MAC and Split MAC 
WIPs. The differences in their respective functional characteristics 


are determined in this state. 


The WIP first broadcasts a Capabilities message as soon as it 


transitions from its Initialization state. The Capabilities message 
serves to discover ACs and contains information on its identity and 
capabilities. 


The AC receiving the Capabilities message transitions from its 
Initialization state. It examines compatibility with respect to the 
WIP type, its capabilities, and responds with an appropriate 
Capabilities Response message. 


The WIP continues to send Capabilities messages at an interval 


specified by the Response Timer until it receives a Capabilities 
Response message from an AC. 
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The AC maintains a count of Capabilities messages received from a 
given WTP, which it uses to ignore WTPs after a limit. This is to 
ensure that rogue WIPs that are not compatible with the AC do not 
repeatedly attempt connections. The limit of connection attempts is 
3 within 60 seconds. 


State transition: Capabilities Exchange -> Connection 
WTP: Upon receiving a positive Capabilities Response message 
from an AC 
AC: Upon receiving a Connection Request message from a WTP 


5.3. Connection 


The Connection state involves establishing a security infrastructure 
between WTPs and an AC. 


The WIP sends a Connection message to trigger the authentication and 
security mechanism, i.e., this message initiates an IPsec security 
association. 


The AC sends a positive Connection Response message after 
establishment of the security association or a negative Connection 
Response message if an error occurs. The AC also monitors the 
receipt of WiCoP control messages to prevent replay attacks. 


The security association between an AC and WTIPs covers mutual 
authentication and also protection for integrity, confidentiality, 
and modification protection for subsequent traffic exchanges. 


In order to avoid forceful disconnections of legitimate WIPs after a 
successful Connection, the AC ignores Capabilities messages received 
with a previously registered WIP identification. 


State transition: Connection -> Configuration 
WTP: Upon successful establishment of security infrastructure 
marked by sending of a Configuration Request message 
AC: Upon receiving Configuration Request message from a WTP 
after successful establishment of security infrastructure 


State transition: Connection -> Capabilities Exchange 
WTP: Upon expiry of the WIP Response Timer before receipt of a 
positive Connection Response message from an AC or upon 
receipt of a negative Connection Response message 
AC: Upon expiry of AC Response Timer before receipt of 
Configuration Request message from WTP 
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5.4. Configuration 


The Configuration state is one in which relatively long-term 
operational parameters, such as those for identification and logical 
groups, are exchanged. These parameters are based on previously 
exchanged capabilities information and network policies. 


The WIP sends a Configuration Request message to the AC. 


The AC first acknowledges the WTP’s Configuration Request, after 
which it sends appropriate configuration information in subsequent 
Configuration Data messages. WiCoP includes MIB objectives as 
message elements in some Configuration Data messages so as to 
simplify WTP configuration. 


The WIP acknowledges Configuration Data messages individually or en 
bloc with Configuration Data Response messages. The Response Timer 
is maintained at both WIP and AC to track the exchanges. 


The AC also establishes relevant processing schedules according to 
the WIP’s architecture design. For example, for Split MAC WTPs, the 
AC arranges its processing schedule to parse IEEE 802.11 control and 
management messages while for Local MAC WIPs, the AC arranges 
schedules processing so as to bypass parsing of IEEE 802.11 
management messages. 


The AC sends a Configure Trigger message after sending all relevant 
configuration information to the WIP. 


The WIP acknowledges a Configure Trigger message with a Configure 
Trigger Response message before activating the previously exchanged 
configuration parameters. 


In order to avoid forceful disconnections of legitimate WIPs after 
successful Configuration, the AC ignores Capabilities messages 
received with a previously registered WIP identification. 


State transition: Configuration -> Operation 
WIP: After receiving final Configuration Data message from the 
AC marked by receipt of a Configure Trigger message from 
the AC 
AC: Upon receiving acknowledgement for Configure Trigger 
message marked by receipt of a Configure Trigger Response 
message from WTP 


State transition: Configuration -> Capabilities Exchange 


WTP: Upon expiry of the WIP Response Timer before receipt of a 
Configure Trigger message from the AC 
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AC: Upon expiry of the AC Response Timer before receipt of 
Configure Data Response message or Configure Trigger 
Response message 


The following describes major configuration aspects of WiCoP. 
5.4.1. Logical Groups 


Configuration Data messages are used to establish logical groups in 
the WLAN and also to separate traffic among them. The logical groups 
are established based on network administrative policies and other 
external considerations. In the IEEE 802.11 use-case, logical groups 
are established with BSSID-based virtual APs and are separated over 
the WiCoP interface using tunnels. 


The AC assigns particular BSSIDs of the WIP to specific VLAN tunnels. 
This assignment is specified to the WTP using the BSSID-TunnelID 
parameter in the Configuration Data message. The logical group 
mapping therefore works across the wireless and WiCoP interfaces. 


The WIP then identifies the specified BSSID and VLAN tunnel as 
corresponding to one logical group. It creates internal state such 
that traffic belonging to the logical group is kept distinct from 
that of other logical groups. 


The AC and WIP also use distinct VLAN tunnels for data and control 
traffic. The ’C’ field in the WiCoP header is used to distinguish 
and assign WiCoP packets to particular data and control VLAN tunnels. 


5.4.2. Resource Control 


The AC sends QoS information using QoS-Value message elements in 
Configuration Data messages. The QoS-Value message element contains 
values for EDCA and HCCA parameters. This information is specified 
for each of the logical groups. In the IEEE 802.11 use-case, QoS- 
Value message elements are specified for each BSSID. 


The WIP configures QoS parameters locally and also forwards relevant 
settings to wireless terminals in appropriate encapsulations. In the 
IEEE 802.11 use-case, QoS parameters are sent to wireless terminals 
in corresponding Beacon or Probe Response frames. 


5.5. Operation 


This is the active operation state of the WLAN in which short-term 
dynamics are examined. 
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The WIP begins operations according to the operational parameters 
exchanged in the previous Configuration state. 


The AC monitors WTPs according to network administrative policies and 
configurations. 


In order to avoid forceful disconnections of legitimate WTPs after 
successful Operation setup, the AC ignores Capabilities messages 
received with a previously registered WIP identification. 


State transition: Operation -> Capabilities Exchange 
WTP: Upon expiry of the WIP Active Presence Timer before receipt 
of a Feedback Response message from the AC 
AC: Upon expiry of the AC Active Presence Timer before receipt 
of a Feedback message from the WTP 


State transition: Operation -5 Initialization 
WIP: Upon receipt of a Reset message from an AC 
AC: Upon receipt of a Reset Response message from a WTP 


The following describes major operation aspects of WiCoP. 
5.5.1. Updates 


The dynamic nature of WLAN systems requires regular updates to 
network operations. 


The AC sends additional configuration information in the 
Configuration Data messages. This is applicable to establishment of 
new logical groups, changes to existing logical groups, changes in 
QoS settings, etc. Configuration information is followed by a 
Configure Trigger message. 


The WIP sends a Configure Trigger Response before activating the 
additional configuration information. 


Configuration updates can be used to clear statistics information by 
reflecting initial values. 


An extreme case of a configuration update involves use of the Reset 
message from the AC, which instructs the WIP to revert to initial 
conditions. The WIP replies with a Reset Response message before 
reverting to its initial state. 


5.5.2. Feedback and Statistics 


The Operation state also sees regular feedback being sent by WTPs to 
the AC. 
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The WIP sends Feedback messages to indicate various statistics and 
congestion condition information. Feedback also includes information 
on the state of the WTP and wireless medium such as queue levels and 
channel interference. Feedback messages are sent with a frequency 
defined by the Feedback Interval. In addition to statistics, the 
Feedback message also serves as a WIP keepalive indicator to the AC. 
Feedback messages combine statistics information together with WTP 
status information. 


The AC monitors Feedback messages for their statistics value and 
implicit indication of WTP activity. The AC also tracks the state of 
congestion at wireless terminals and WIPs. This information enables 
the AC to adapt its downstream transmissions, such as scheduling 
transmission away from congested WTPs, so as to relieve congestion. 


The AC additionally uses the Feedback message to randomly determine 
the active state of WIPs. An active WIP replies with a corresponding 
Feedback Response message. 

5.5.3. Non-Periodic Events 
The WIP and AC use the Notification message for non-periodic events. 
They send Notification messages to indicate error conditions or 


drastic changes in congestion state. 


The recipient of the Notification message acknowledges with a 


Notification Response message. The response may contain information 
on rectifying the error or may simply be an acknowledgement of the 
Notification. 

5.5.4. Firmware Trigger 


The AC sends a Firmware Download message to update firmware at WIPs. 
The Firmware Download message contains TFTP information, which the 
WIP uses to refresh its firmware. This is used when a new version of 
firmware is available for the WTPs. 


The WIP acknowledges new firmware with a Firmware Download Response 
message after which it is activated. 


5.5.5. Wireless Terminal Management 


The Operation state of WiCoP also involves configuration of WIPs and 
the AC with wireless terminal-specific information. 
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Here the Terminal Addition message is used in response to a new 
wireless terminal entering the WLAN. This message may be sent by 
either the WIPs or the AC, depending on the WiCoP interface being 
used. The recipient of this message replies with the Terminal 
Addition Response message. 


The Terminal Deletion message is used when a wireless terminal leaves 
the WLAN. This is used to delete state information that was 
maintained by either the WTPs or the AC. It is acknowledged with the 
Terminal Deletion Response message. 


Figure 8 below illustrates the exchange of Terminal Addition and 
Terminal Deletion messages for both Local-MAC- and Split-MAC-based 
WiCoP interfaces. 


Here the WiCoP Terminal Addition message is triggered as a response 
to an IEEE 802.11 Association message. In the case of Local MAC 
architecture, the WIP sends the message to the AC. However, in the 
Split MAC architecture, Terminal Addition is sent from an AC to the 
WTP. 


Iino, et al. Historic [Page 44] 


RFC 5414 WiCoP February 2010 


+---------- + +--------------- + po + 
| Terminal Local MAC WTP | ac | 
+---------- + +--------------- + po + 
| | | 
| IEEE 802.11 Association | WiCoP 
| ------------------------- >| Terminal Addition | 
| | > | 
| WiCoP Terminal | 
| |< | 
| IEEE 802.11 Association | Addition Response | 
| | | 
| Response | | 
| | | 
| | 
| | 
| +--------------- + | 
| | Split MAC WTP | 
| $--------------- + | 
| 
| | | 
| IEEE 802.11 Association | | 
| an >| | 
| | IEEE 802.11 Association | 
> 
| | (Over WiCoP) 
| | | 
| | | 
| | WiCoP | 
| | Terminal Addition | 
| | 
| | | 
| | WiCoP Terminal | 
| | > | 
| | Addition Response | 
| | IEEE 802.11 Association | 
| |< | 
| | Response (Over WiCoP) | 
| IEEE 802.11 Association | | 
< A A O A A ee 2 in 
Response | | 
Figure 8 
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5.5.6. Key Configuration 


One of the differences between Split MAC and Local MAC WIPs is the 
location of the over-the-air encryption. Some Split MAC and Local 
MAC WIPs perform encryption locally while others leave it to the AC. 
WiCoP accommodates these differences by enabling security key 
configuration in those cases where encryption is performed at the 
WIP. The encryption setup process is therefore contingent on the 
WiCoP protocol interface. 


When dynamic WEP is used, the WiCoP Key Configuration message is used 
to notify WIPs of encryption keys for each associated wireless 
terminal. Here, the EAP over LAN (FAPoL) Key frame is encapsulated 
in the Key Configuration message and sent to a WIP. Upon receiving 
the Key Configuration message, the WIP sets the encryption key in its 
local security table, decapsulates the EAPOL Key frame and forwards 
it to the wireless terminal. This is illustrated in Figure 9. 
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| | | 
| | 
|< >| 
| | | 
| | | 
PMK PMK 
| | | 
| | | 
|e |< | 
| EAPoL Packet | WiCoP Control Packet | 
| | (Key Configuration) | 
| | +----------------------- + 
\|- Encryption-Data 
Unicast-Key 
Set Receive |- EAP-Frame 
Unicast-Key P aaa | Key Signature 
| $----------------------- + 


WiCoP Control Packet 
(Key Configuration 
Response ) 


WiCoP Control Packet 
(Key Configuration) 


\|- Encryption-Data 
Broadcast-Key 
Set Receive |- EAP-Frame 
Broadcast-Key Broadcast-Key | Key Signature 


| | Broadcast Key 


WiCoP Control Packet | 
(Key Configuration | 
Response ) | 


| | 
| | 
| | 
| | 
| | 
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When WPA or IEEE 802.11i is used in WLAN architectures in which the 
authenticator is located at the AC and encryption points at WIPs, the 
exchanges of the 4-way handshake are managed distinctly. This is 
because the AC is no longer in a position to calculate the KeyMIC as 
it is not aware of the KeyRSC sequence counter. So here, a WiCoP Key 
Configuration message is used to transport the 3rd message of the 
4-way handshake -- containing the EAPoL-Key -- with unassigned KeyRSC 
and KeyMIC fields. When the WIP receives the WiCoP Key Configuration 
message, it first assigns the sequence number value to the KeyRSC 
field. Then, the WIP calculates the KeyMIC value using the PTK and 
KeyRSC. So, the WiCoP Key Configuration message allows the KeyMIC to 
be calculated at the WIPs instead of the AC. The GTK-Flag message 
element is used to determine how the KeyMIC is calculated -- in case 
of a new GTK, KeyMIC is computed with a KeyRSC value of 0 and in case 
of an existing GTK, KeyMIC is computed with a KeyRSC value 
corresponding to the actual counter. 


Figure 10 illustrates this case where the WiCoP common header is 
either 'M = 0 and ’D’ = 0 or 'M = 1 and 'D” = 1. 
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802.1x Authentication 


< > 
| 
| 
| | | 
Generate Generate 
SNonce | ANonce 
| 


| Message 1 | 


| EAPOL Packet WiCoP Data Packet 


| 
Receive | | 
ANonce | | 
Generate | | 
PTK | | 
| | | 
Message 2 
| ------------------------- > | --------------------------- > 
| EAPOL Packet | WiCoP Data Pakcet | 
| | Receive 
| | SN NG 
| 
Generate 
| | PTK 
| | GTK 
| Message 3 | 
| <------------------------- < | 
| EAPOL Packet | WiCoP Control Packet | 
| | (Key Configuration) | 
| +----------------------- + 
| | \|- GTK-Flag | 
Receive Receive |- Encryption-Data(PTK) | 
GTK PTK |- Encryption-Data(GTK) | 
| GTK |- EAP-Frame | 


| EAPoL Packet | WiCoP Data Pakcet 


Figure 10 


Tino, et al. Historic [Page 49] 


RFC 5414 WiCoP February 2010 


The 1st, 2nd, and 4th messages of the 4-way handshake are transported 
in WiCoP data packets that are assigned priorities similar to that of 
WiCoP control packets. 


Similarly, for the group key handshake in WPA and IEEE 802.11i, the 
1st message of the handshake is transported using the WiCoP Key 
Configuration message with unassigned KeyRSC. The WIP again assigns 
the sequence number value to the KeyRSC and then calculates the 
KeyMIC. The 2nd message of the handshake however is transported in 
WiCoP data packets with priorities similar to that of WiCoP control 
packets. This is illustrated in Figure 11. 


WiCoP Control Packet 


EAPoL Packet | 
| (Key Configuration) 


| +----------------------- + 
| | \|- GTK-Flag 
Receive Receive - Encryption-Data (GTK) 
GTK GTK |- EAP-Frame | 
| | +----------------------- + 
| | | 
| | 
| Message 2 | 
|------------------------- > | La >| 
| EAPOL Packet | WiCoP Data Pakcet | 
| | 


Figure 11 


The Key Configuration Response message is used by the WIP to notify 
the AC of the encryption setup process. 
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6. WiCoP Performance 


WiCoP is an efficient protocol. This section illustrates various 
examples of its efficiency. 


6.1. Operational Efficiency 


The fact that WiCoP requires a single operation to distinguish and 
manage WTPs of different designs makes it operationally efficient. 
Because WiCoP assigns dedicated classification bits in the common 
header, an AC needs to parse incoming packets only once to determine 
the particular manner in which it is to be processed. Without the 
dedicated classifications in the common header, an AC would have to 
perform a lookup after parsing every incoming packet, which would 
result in delaying processing. The scale and sensitivity of large- 
scale deployments require that WLAN control protocols be efficient in 
operation. 


6.2. Semantic Efficiency 


In certain cases, WiCoP combines utilities in a single operation. 

One particular case is that of statistics and activity feedback. 
Here, WIPs regularly send a single Feedback message containing 
statistics and other state information, which also acts as an 
implicit keepalive mechanism. This helps to reduce the number of 
message exchanges and also simplifies protocol implementation. 
Similarly, the Capabilities messages serve the purpose of finding ACs 
as well as informing them of WIP capabilities and design. 


7. Summary and Conclusion 


The Wireless LAN Control Protocol presents a solution for managing 
large-scale WLANs with diverse elements. It addresses the challenges 
presented in the CAPWAP Problem Statement [RFC3990] and realizes the 
requirements of the CAPWAP Objectives [RFC4564]. 


WiCoP enables integral control of Split MAC and Local MAC WIPs by 
defining appropriate differentiators within the protocol message 
exchanges and processes. It addresses architecture designs in which 
the authenticator and encryption points are located on distinct 
entities. In doing so, WiCoP realizes the interoperability objective 
and its benefits. 


WiCoP also addresses shared WLAN deployments by configuring and 
managing WIPs on a logical group basis. It is further provisioned to 
separate control and data traffic within WLANs. So, the protocol 
addresses the objectives of logical groups and traffic separation. 
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Overall, the specifications presented in this document allow for an 
effective WLAN control and provisioning protocol. 


8. Security Considerations 


Illegitimate WTPs and ACs pose a significant threat to WLAN security. 
This can be mitigated by requiring all WiCoP entities to be mutually 
authenticated before initiating critical protocol exchanges. WiCoP 
includes a trigger for a suitable authentication mechanism. This is 
to accommodate a different security mechanism that may be used 
between WIPs and the AC, depending on the nature of the deployment. 


In extension to mutual authentication, the subsequent exchange of 
protocol information between WIPs and the AC need to be protected. 
The exchanges have to be protected against alterations of any sort 
and Denial-of-Service (DoS) attacks. Also, the information should 
not be accessible to any third party. Encryption of protocol 
exchanges is therefore necessary. WiCoP includes appropriate 
procedures to select and establish a security association between 
WTPs and the AC in the Connection state. 


Architecture designs in which authentication is performed at the AC 
and encryption at the WTPs can be exposed to the threat of replay 
attacks. Since the AC will not be aware of the exact value of the 
sequence counter, it will not make the corresponding assignment 
within the 4-way handshake. This leaves the wireless terminal to 
accept all incoming frames, including illegitimate frames, as it 
cannot verify the sequence counter value. Such a threat needs to 
protected against by allowing the WTP to assign the correct value of 
the sequence counter. WiCoP accomplishes this by sending the 3rd 
message of the 4-way handshake within a control message to the WTP, 
which then updates the sequence counter field before forwarding it to 
the wireless terminals. 


Another issue to consider is that of rogue WIPs using identifiers 
similar to that of legitimate WIPs. In such instances, a rogue WTP 
can send a Capabilities message to the AC, thereby causing 
disconnection of the existing legitimate WTP of the same identifier. 
It is important for the AC to ignore Capabilities messages received 
with existing identifiers. 
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